-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
template: Clean up outputs #49
base: master
Are you sure you want to change the base?
template: Clean up outputs #49
Conversation
Clean up the template functions and outputs using the legacyPackages napalm output and an eta reduction.
# Example package | ||
hello-world = final.napalm.buildPackage ./hello-world { }; | ||
}; | ||
overlay = final: prev: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about this. On one hand this makes the overlay self-contained. On the other, it is no longer pure – and if the overlay no longer works with a single coherent set of packages, there are not many reasons to choose it over just legacyPackages
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I'm not very familiar with both creating and using overlays; I use them very coarsely in my dotfiles when I use them at all. Since the package requires napalm to build, providing it purely would require adding the napalm overlay to prev
, right? Is something like this possible?
let
pkg = import prev {
overlays = [ napalm.overlay ];
};
in
{
hello-world = pkg.buildPackage ./hello-world { };
};
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nix flake check
doesn't seem to error on it, so I'll test it out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The answer is no, it does not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would re-create a new Nixpkgs instance from scratch, likely discarding other overlays in the stack.
You could do something like the following:
final: prev:
let
ourOverlay = final: prev:
{
hello-world = prev.napalm.buildPackage ./hello-world { };
};
in
prev.lib.composeExtensions napalm.overlay ourOverlay
but that would also override napalm
people put in their overlays
.
Or maybe something like:
final: prev:
let
pkgsWithNapalm = napalm.overlay final prev;
in
{
hello-world = pkgsWithNapalm.napalm.buildPackage ./hello-world { };
};
But that would still not allow people to override napalm.
We could allow that using conditional stacking:
final: prev:
let
pkgsWithNapalm = if prev ? napalm then prev else napalm.overlay final prev;
in
{
hello-world = pkgsWithNapalm.napalm.buildPackage ./hello-world { };
};
But I think that is too magic and would just befuddle people.
So I tend to use just plain old
final: prev:
{
hello-world = prev.napalm.buildPackage ./hello-world { };
};
And mention the dependency in readme.
But maybe there is some other idiom concerning interdependent overlays that I am not aware of. Maybe ask on Discourse or Matrix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the conditional stacking, but yeah, might be complex to have in a template. Not sure that it's common though to have an external builder be passed purely though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I added an implementation of the conditional stacking I've managed to get working right, alongside some explanatory comments. It's close to what you had, but with napalm.buildPackage
as the checked attr, as that's both specifically what we need, and should help avoid collision problems (e.g. there's already a napalm package in nixpkgs, but it's different).
It's probably enough to do things like this, as overlays themselves are more of an advanced use-case.
EDIT: Got it working in 7bfe032 specifically.
ed42e83
to
5090daa
Compare
Replace the impure overlay with a pure one that includes the dependent napalm overlay stacked conditionally. Using `napalm.buildPackage`, as there _is_ a package in nixpkgs called "napalm", but it's a different project, and the buildPackage function is what we're looking to use anyways. Signed-off-by: David Houston <[email protected]>
5090daa
to
7bfe032
Compare
Clean up the template functions and outputs using the legacyPackages napalm output and an eta reduction.
It might also be easier to clean things up if we used flake-utils, but not sure if we want to force that on downstream users.